Tidy Ecology — project instructions

Ez a szöveg a Claude-projekt „Instructions” mezőjébe megy, NEM a knowledge-be. Minden chatre érvényes.

A projekt egy mondatban

Anonim, angol nyelvű R és QGIS ökológiai tutorial-blog „Tidy Ecology” néven, Quarto + Netlify alapon, biológusoknak/ökológusoknak. A monetizáció szándékosan későbbre halasztva. Élő: https://tidyecology.com.

Hol mi van (fájl-térkép)

A régi egyfájlos kézikönyv szét van vágva változás-ütem szerint. A §-számok KANONIKUS AZONOSÍTÓK maradnak — a hivatkozások („lásd a 9. pontban”, „a 13.19 szerint”) végig működnek, csak a szakasz már másik fájlban lakik.

fájl	tartalom	mikor nyúlj hozzá
(ez a szöveg)	§0 recept, §1, §4 anonimitás, §8 AI-nyom, §13 állandó szabályok	szinte soha
`01-konvenciok.md`	§3 hosting/deploy, §5 fájlstruktúra, §6 design, §14 SEO/IndexNow	ha az infra változik
`02-tool-leckek.md`	§9 build-workflow + tool-leckék	ha új általánosítható lecke jön
`03-poszt-index.md`	§7 poszt-index (mind a 682)	minden batch (új sorok)
`04-allapot.md`	§2 állapot, §10 verzió-történet, §11 pending/ledgerek	minden menet
`05-backlog.md`	§12 monetizáció, §15 ötletbank, §16 növekedési backlog	ritkán

A KANONIKUS FORRÁS a projekt-mappa a felhasználó gépén, nem ez a knowledge. A per-poszt részletek (verifikált számok, seed, DOI) a posts/<slug>/index.qmd-ben élnek — a chunkokban a számok, a References-ben a DOI-k, a kódban a seed. Ha konkrét szám/DOI/seed kell, vagy meglévő posztot kell szerkeszteni: kérd be a QMD-t vagy a teljes projektmappát. A knowledge navigál, nem archivál.

0. A batch-recept (a következő instance KÖVESSE EZT)

Az instance szöveget/fájlokat ad ki, a felhasználó frissíti a projektet. Hogy mi van már lefedve, azt a §7 poszt-indexe mondja meg (03-poszt-index.md) — ez a duplikáció-védelem, és teljes egészében olvasd, ne csak keress benne.

A session végén KÉT dolgot adj ki:

Az új posztok — mappánként index.qmd + thumbnail.png, a minőség-kapun átengedve (§8 + §9).
A megváltozott knowledge-fájlok a zip _knowledge/ mappájában (NEM a gyökérben: a Quarto a gyökér .md-jeit is renderelné, tehát egy ottfelejtett 01-konvenciok.md publikus oldal lenne a tidyecology.com/01-konvenciok.html-en, és az IndexNow be is küldené. Az aláhúzásos mappát a Quarto sosem nézi, ugyanaz a szabály, ami a _freeze/-t is kihagyja.)
- 03-poszt-index.md — az új sorok a §7-táblába (a formátum kötelező: ≤150 karakteres téma-cella, lásd lent).
- 04-allapot.md — az állapot-blokk számai + a „Legutóbbi menet” bekezdés + szükség esetén a §11 ledger.
- 02-tool-leckek.md — CSAK ha új, általánosítható tool-lecke jött elő (folytatólagos betűzés, a §9 betű-jegyzete szerint).
- A többihez (01-konvenciok.md, 05-backlog.md) alap esetben NE nyúlj.

A leadás formátuma (KÖTELEZŐ csomagolás, egy poszt = egy mappa). A session-végi kimenet EGY zip (név: tidy-ecology-<temakor>-v<NN>.zip), amelyben MINDEN poszt a SAJÁT, a slug-járól elnevezett mappájában van, a posts/ alá csoportosítva: posztonként posts/<slug>/index.qmd + posts/<slug>/thumbnail.png. A mappa-név MINDIG a poszt slug-ja, mert ez lesz a Quarto-URL. A megváltozott knowledge-fájlok a zip GYÖKERÉBEN. Így a felhasználó a zipet a projekt-gyökérben kibontva a posts/<slug>/ mappák egyből a helyükre kerülnek, majd EGY quarto publish netlify. NE adj ki laza, mappa nélküli fájlokat, és NE válaszd szét a thumbnailt a qmd-től. (A per-poszt in-poszt ábrák a QMD chunkjaiból renderelődnek deploykor, őket NEM kell külön képfájlként csomagolni; CSAK a thumbnail.png a commitolt asset, mert a front matter image: mezője hivatkozza.)

A felhasználó gépén ezután: a poszt-mappákat a projekt posts/-ába, a megváltozott knowledge-fájlokat a projekt-knowledge-be cserélni, majd egyetlen quarto publish netlify, majd a MANDATORY IndexNow (§13.13 + §14).

A §7-sorok formátuma (KÖTELEZŐ — ez a drift fő forrása volt)

A téma-cella ≤150 karakter, és CSAK a témát + a kulcs-tételt viszi. A per-poszt részletek NEM ide valók (§0 purl-elv): se seed, se verifikált szám, se DOI, se ábra-szám, se References — azok a QMD-ben élnek, kanonikusan. A bevált forma:

téma / módszer; a kulcs-tétel egy tagmondatban; [ha kell] oszinte hatar: <a fő korlát>

A táblában a | karaktert escape-eld (\|) — feltételes valószínűségnél (sigma2\|mu) ez kötelező, különben szétdobja a táblát. (Ez 24 soron el volt rontva a v121-ig.)

A darabszám-politika

A batch-méret a verifikációs kontextus körül mozog, nem a knowledge mérete körül. Kód-nehéz tutorial ~4/batch; próza-dominált koncepció-poszt olcsóbb, abból több fér vagy keverhető (pl. 3-4 kód + 2-3 koncepció). A minőség-kapu FIX; ha a kontextus fogy, állj meg tiszta poszt-határon és add le a verifikáltat (tiszta 4 > csonka 6). Részletek: 01-konvenciok.md §3 „Hány poszt egy batch”.

Témaválasztás

Autonóm, „max effort” alapból — alapos, önálló munka, hízelgés nélkül. A felhasználó terse, gyakorlati.

4. ANONIMITÁS: kritikus, soha ne sérüljön

A tulajdonos valódi neve (Nagy-Máté Botond / Botond) SEHOL nem szerepelhet a NYILVÁNOS felületen: sem a látható oldalon, sem a publikus metaadatban.

Szerző = márkanév. A posts/_metadata.yml author: "Tidy Ecology" mezője hajtja a látható bylint ÉS az index.xml (RSS) <dc:creator>-ját. A poszt front matterébe SOHA ne írj author-t (örökli a márkanevet). Minden poszt így készült.
About oldal a blogról szól, nem személyről.
Kolozsvári koordináta a hero eyebrow-jában (N 46.77° · E 23.59°) SZÁNDÉKOSAN marad (önmagában nem azonosító). A richness-mapping-sf poszt szintetikus adata is e koordináta környékére esik, de a szövegben explicit „synthetic / illustrative”, így nem implikál valós terepi helyet.
Domain WHOIS: a tidyecology.com Porkbun Contact Privacy BE van kapcsolva → a nyilvános WHOIS a proxy-adatot mutatja, a regisztráns „Tidy Ecology”.

Anonimitás — ŐSZINTE határok (mit rejt és mit nem a WHOIS-privacy)

A WHOIS-privacy a nyilvános lekérdezések elől rejt. NEM rejt a regisztrátor (Porkbun) és a kártyás fizetés elől — ők ismerik a valódi azonosságot. A felhasználó fenyegetésmodelljéhez (ne tudja diák/munkahely/nyilvánosság a blogot a nevéhez kötni) ez elég. FIGYELEM: a Porkbun fiók-nézetében a regisztráns VALÓDI címe és telefonszáma látszik — ilyen screenshotot SOHA ne tegyél nyilvános helyre (fórum, blog, GitHub).

Hátralévő anonimitási teendők

Gmail megjelenítési név legyen „Tidy Ecology” (ha még nem az).
Ne linkeld a blogot azonosítható fiókból, amíg az anonimitás cél. (A GSC/Bing verifikáció NEM publikus link, így rendben.)

Hírlevél (Buttondown) — anonimitási vonatkozás

A hírlevél a Buttondownon fut (buttondown.com/tidyecology).

A felhasználónév (tidyecology) PUBLIKUS: megjelenik a subscribe.html form action URL-jében (.../embed-subscribe/tidyecology) ÉS a buttondown.com/tidyecology oldalon. Ezért márkanév, SOHA nem a valódi név.
Feladó-név = „Tidy Ecology”. A címzettek ezt látják.
Számlázás (100 feliratkozó fölött, 9 USD/hó Basic): a kártya/számlázás a valódi azonosságot CSAK a Buttondown felé fedi fel, pontosan mint a Porkbun. A PUBLIKUS anonimitást nem érinti, amíg a feladó márkanév marad és számlázási adat nem kerül publikus helyre.
Double opt-in a Buttondownon KÖTELEZŐ/alapból be → a GDPR-hozzájárulás bizonyítéka automatikus; a nyomkövetés (open/click) új fiókon alapból KI.

8. AI-nyom mentesség

A hosszú gondolatjel (em-dash) TILTOTT a BLOGPOSZTOKBAN mindenhol (próza, cím, alt-szöveg, kódkomment, képaláírás). Cél: 0×. Helyette kettőspont, pontosvessző, zárójel. (A knowledge-fájlok belső doksik, NEM blogtartalom — ott az em-dash megengedett.)
Sablonos szerkezetek kerülendők: reflexszerű hármas felsorolások, „kulcsszó + gondolatjel + leírás” bulletek, túl párhuzamos mondatok.
AI-szókincs kerülendő: delve, leverage, robust, seamless, „it’s worth noting”, moreover, furthermore, notably, crucial, utilize, realm, tapestry, underscore, stb.

13. Állandó szabályok (felhasználói kérések, MINDEN posztra)

Session-független konvenciók; minden új poszt és minden szerkesztés tartsa be.

Nincs author a poszt front matterében — a posts/_metadata.yml author: "Tidy Ecology"-ja hajtja a bylint és az RSS <dc:creator>-t. Valódi név SEHOL (§4).
Kategóriák kisbetűvel, KIVÉTEL a tulajdonnevek/program-/csomag-/betűszó-nevek: R, QGIS, PERMANOVA, GLM, GLMM, GAMs, GIS, GeoPackage, GLS, ANOVA, vegan, sf, mgcv, lme4, nlme, picante, ggplot2. A categories ökológiai kontextust is hordozzon („ecology tutorial”).
Cím ≤55 karakter (a renderelt <title> = title + „ – Tidy Ecology” = +15 → ≤70; a Bing 70-nél figyelmeztet). Kulcsszó-mag elöl.
Minden ábra-chunk kap #| fig-alt:-ot (a fig-cap + plot-kód alapján; additív SEO/akadálymentesség).
description minden poszton/oldalon (~150-160 karakter, BRIT helyesírás, ökológiai kulcsszavakkal).
Kompakt citáció (cikk-cím NÉLKÜL): „Szerző Év Folyóirat Vol(Issue):Pages (DOI)” vagy könyv: cím + ISBN. Em-dash helyett kettőspont/pontosvessző/zárójel. Ékezetes szerzőnév ASCII-ra transzliterálva (a DOI egyértelműsít); a cikk-cím elhagyása AI-szó-védelem is (§8).
Deploy-sor minden posztnál a §7-ben (mappa-hely, R-csomagok, dátum/lista-pozíció, böngészős ellenőrzés); leadáskor a deploy-infó mellékelendő (§3).
Minőség-kapu posztonként, NEM alku tárgya (§8 + §9): Rscript-futtatás, knitr::purl chunk-kinyerés + újrafuttatás (MINDEN idézett szám chunk-fedett, a QMD-chunk az igazságforrás), ábra view-val, em-dash/en-dash/nem-ASCII/AI-szó = 0 (Python), DOI kétszer, a §13.26 szerinti két API-ból, CÍM-egyeztetéssel.
Élő ellenőrzés a böngészőben, NEM web_fetch (§9: a web_fetch megbízhatatlan az élő site-ra; élő DNS/HTTP mobilneten/DoH-val, nem a gép lokális feloldójából).
Batch-deploy: egy session több posztot készít, végén EGY zip, a felhasználónál EGY quarto publish netlify (kredit-takarékosság, §3).
Témaválasztás autonóm („max effort” alapból). Darabszám: lásd a §0 recept „darabszám-politika” pontját.
Batch-leadás: két kimenet — lásd a §0 receptet. Külön napló/toldalék NINCS: a per-poszt specifikáció a QMD-forrásban él (purl-elv).
IndexNow-beküldés deploy után (§14). A TELJES SITEMAP BEKÜLDÉSE MEGSZŰNT (v282, 2026-09-05). A Bing Webmaster Tools „IndexNow is in batch mode” figyelmeztetést ad rá, és 14 700 beküldés áll 723 URL-re; a Bing szerint ez indexelési késleltetést okozhat. Beküldeni CSAK az ÚJ és a ténylegesen módosult URL-eket kell. A beküldés a felhasználó döntése, és a kérdésben meg kell mondani, hány URL-ről van szó és hány ÚJ.

Elsődlegesen a menet maga tudja, mely slugokat érintette, tehát azokat sorold fel:
```
./indexnow.sh https://tidyecology.com/posts/<slug-1>/ https://tidyecology.com/posts/<slug-2>/
```
Ha a lista elveszett, a sitemap lastmod mezőjéből származtatható. Ez fájl-mtime közelítés, tehát felülbecsül, de nagyságrenddel kevesebbet a teljes sitemapnál (a fán próbálva: 723 helyett 99). Előbb nézd meg a darabszámot:
```
python3 -c "import re,datetime;d=open('_site/sitemap.xml').read();cut=str(datetime.date.today()-datetime.timedelta(days=1));u=[x for x,m in re.findall(r'<loc>([^<]+)</loc>\s*<lastmod>([^<]+)</lastmod>',d) if m>=cut];print(len(u));print('\n'.join(u))"
```
majd ugyanezzel a kifejezéssel küldd be:
```
./indexnow.sh $(python3 -c "import re,datetime;d=open('_site/sitemap.xml').read();cut=str(datetime.date.today()-datetime.timedelta(days=1));u=[x for x,m in re.findall(r'<loc>([^<]+)</loc>\s*<lastmod>([^<]+)</lastmod>',d) if m>=cut];print(' '.join(u))")
```
(kulcs 5bc15572323203b26dc6f63128fad6b9) Csak Bing + résztvevők; a Google GSC/sitemapen megy. A kulcsfájl (5bc...txt) a resources-ben legyen (§3).
Start-here hub karbantartása: létezik egy start-here/index.qmd navigációs hub (navbarban „Start here”, canonical redirect a _redirects-ben), amely az összes tutorial-posztot workflow-szakaszokba rendezi. Minden ÚJ poszt leadásakor egy sorral bővítsd a start-here megfelelő szakaszát (abszolút /posts/<slug>/ link + rövid, ASCII-only leírás). Fájl-hiány esetén az új alszakasz/sor pontos szövege a §11 ledgerbe kerül (04-allapot.md), és a következő deploykor kerül be.
„## Related tutorials” blokk minden poszt végén: minden ÚJ tutorial-poszt kap egy záró „## Related tutorials” blokkot (max 4 kapcsolódó, relatív ../<slug>/ link, a start-here-rel egyező címkékkel; klaszter-logika: a legközelebbi témarokonok + indokolt cross-cluster bridge). A welcome (meta) kivétel. A meglévő „Where to go next” prózát nem váltja ki, mellette áll.
Belső-link-ellenőrzés a kapuban: minden belső ../<slug>/ és /posts/<slug>/ hivatkozást vess össze a valódi poszt-mappák (a §7 slug-listája) ellen — egy elgépelt slug némán 404-et ad. Egysoros Python/grep audit a posts/ fölött elég. Az audit a TELJES posts/-ra fusson, ne csak a batch-re (§9 (kkkk): így derült ki a #217 néma 404-e, ami a v100-deploy óta élt).
Per-poszt JSON-LD + canonical AUTOMATIKUS: a seo-jsonld.lua filter (a _quarto.yml filters: alatt) minden posts/<slug>/index.qmd-hez beszúr egy TechArticle JSON-LD-t + self-canonicalt a <head>-be, a front matter title/description/date/image alapján, #org/#website-re hivatkozva (márka-only, anonim). ÚJ posztnál nincs kézi teendő; opcionálisan date-modified: a front matterbe jelentős szerkesztés után. Minden más HTML-oldal (home/about/contact/start-here/legal) IS kap self-canonicalt (a 404 KIVÉTEL); a TechArticle JSON-LD CSAK a posztokon marad.
Kategória-higiénia: a kategóriák kisbetűsek, kivéve tulajdonnév/csomag; szinonimákat óvatosan vonj össze (a GLM/regression/linear models klasztert NE). A homepage kategória-felhő KI (index.qmd listing: categories: false). Új poszt kapjon ecology tutorial címkét.
Reciprok belső-linkelés (régi→új) — a „Related tutorials” kétirányúsítása („B” szint): a 15. pont az ÚJ→régi irányt fedi; a 19. az ELLENIRÁNY. Minden ÚJ poszt leadásakor:
- (a) célválasztás — SPECIFIKUS egyezés, nem tág kategória: a §7 poszt-indexéből válaszd ki azt az 1–3 meglévő posztot, amelynek az új poszt erős, szűk párja — ugyanaz a szűk altéma/módszer (NEM pusztán közös R/ecology tutorial/vegan címke), VAGY explicit prerekvizit↔︎következő-lépés páros, VAGY „gyakori hibák / mikor-ne / értelmezés” társ ugyanarra a módszerre. Ha nincs 1–3 valóban erős pár, kevesebb (akár 0) is jó; gyenge linket NE erőltess.
- (b) beszúrás cap-tisztelettel: a cél-poszt „## Related tutorials” blokkjába vedd fel az - [Új cím](../<uj-slug>/) sort; ha a blokk már tele (4 link), VAGY hagyd ki a célt, VAGY cseréld a leggyengébb meglévőt — de CSAK ha az új egyértelműen relevánsabb. A 4-es cap SOHA nem léphető túl. Csere előtt ellenőrizd, hogy a kidobott cél ≥2 inbounddal marad (orphan-biztos).
- (c) a kategóriák viszik a maradékot (automatikus, kliens-oldali tag-szűrő) — ehhez NEM kell régi posztot szerkeszteni.
- (d) a KAPU a szerkesztett régi posztokra IS fut: a reciprok-beszúrás élő poszt forrását módosítja (freeze: auto újrarendereli), ezért a 8./16. pont ellenőrzése MINDEN érintett régi poszton is fusson.
- (e) Fájl-hiány esetén: ha a projekt-fájlok NINCSENEK a kontextusban, a konkrét reciprok-editeket (cél-fájl + beszúrandó Related-sor) a §11 ledgerbe írd (04-allapot.md); a következő deploykor a felhasználó megadja a fájlokat, akkor alkalmazd + futtasd a kaput, majd TÖRÖLD a tételt a ledgerből.
Periodikus belső-link-audit (~20 posztonként): nem batch-enként, hanem nagyjából minden 20. poszt körül futtass egy auditot a posts/ fölött: (a) építs irányított link-gráfot a „## Related tutorials” blokkokból; (b) számold a BEFELÉ mutató linkeket poszt-onként; (c) jelezd az árvákat (<2 inbound), a törött relatív linkeket, a cap-sértéseket (>4) és az önhivatkozást; (d) a leggyengébb árvákat töltsd fel 1–3 releváns poszt „Related” blokkjába. A slugot SOSE memóriából — grep a §7-ből.
Teljes mappaszerkezet-átadás: minden batch/revízió leadásakor a kimenet a TELJES projekt-mappa (minden poszt, _quarto.yml, _publish.yml, _redirects, a filterek pl. seo-jsonld.lua, post-render-sitemap.R, indexnow.sh, minden resource és _freeze/), NEM csak a módosított fájlok. Kizárva: _site/, .quarto/, __MACOSX, .DS_Store, *.bak.
Adatkezelés-szinkron a privacy-policyval: ha az oldal ÚJ személyes adatot kezd gyűjteni (most: hírlevél-email a Buttondownon; később: display/affiliate süti), a legal/privacy.qmd UGYANABBAN a leadásban frissüljön. A hírlevél-form (subscribe.html) a /legal/privacy.html-re linkel → ez a link ne törjön. Cookie-sáv CSAK akkor kell, ha az oldal MAGA tesz le sütit (a Buttondown-embed NEM tesz).
Dup-label higiénia: a chunk-label SOSE csupasz null/bool/szám, és ne legyen {r nev} + #| label: párhuzam ugyanabban a chunkban (knitr „Duplicated chunk option(s) ‘label’” warning). A {r nev} fejléc-stílus #| label: NÉLKÜL legitim (41 élő poszt így csinálja, a @fig-* kereszthivatkozás működik).
Pillér-oldalak (topics/<klaszter>/index.qmd): a pillér NEM poszt (nincs date, author, image, sem kód), ezért a prózájában NULLA szám állhat — nincs chunk → nincs purl → a 13.8 nem tud futni rajta; a szám a posztban él, kanonikusan. Mag-tag az a poszt, aminek a MÓDSZERE maga a pillér head-termje, nem az, ami csak használja (az integrált SDM occupancyt HASZNÁL → farok); a rokonok a záró „Where this connects” farokba mennek (egyirányú, a 13.19 négyes cap-jét nem érinti). A tartalomjegyzék a start-here szakaszaiból jön, nem friss taxonómiából; a link-címkék a hub címkéit követik, a per-link egysorosok viszont ÚJRA íródnak (különben a pillér a hub duplikátuma). Bármely ÚJ szekció-index (<dir>/index.qmd) KÖTELEZŐEN kap egy ágat a seo-jsonld.lua canonical_path()-jában — e nélkül a fallback a FŐOLDALRA kanonikalizálja, azaz az oldal némán kiesik az indexből ((fffff)-lecke). A /topics/ ág és a _redirects topics-301 a v137 óta generikus, tehát új pillérhez már csak: oldal + navbar-sor + hub-sor + legalább 2 befelé mutató oldal-link.
Szekció-sorrend a poszt végén (v212 óta érvényes): a ## References a MÁSODIK-UTOLSÓ szekció (és a cikk része marad), a ## Related tutorials az UTOLSÓ, minden poszton. Ha van ## Where to go next önálló H2, az a References ELÉ kerül. A welcome (meta-poszt) a dokumentált kivétel: egyik szekciója sincs meg. ÚJ posztra és SZERKESZTETT posztra egyaránt áll. Ellenőrzés a projekt gyökeréből:
```
python3 _gate/section-order-sweep.py            # száraz futás, csak jelent
python3 _gate/section-order-sweep.py --apply    # javít is
```
Elvárt kimenet a jelenlegi fán: valtozo: 0 | kihagyva: 0. A sweep kód-fence-maszkolással dolgozik (különben egy R-komment ## ... sora H2-nek számítana), és KIZÁRÓLAG a két szekciót mozgatja; biztonsági feltétel minden fájlra, hogy a sor-multihalmaz a szerkesztés előtt és után azonos.
A DOI második forrása NEM a kiadó oldala (v214 óta érvényes): a 8. pont azt követeli, hogy minden DOI kétszer legyen igazolva. A kiadó-oldalak (Sage, Wiley, Taylor & Francis, Project Euclid, JSTOR) időközben többnyire 403/429-cel válaszolnak a WebFetch-re, tehát a „publisher-szintű” megfogalmazás gyakorlatban nem teljesíthető. A két forrás, ami MEGY és független:
```
https://api.crossref.org/works/<doi>
https://api.openalex.org/works/doi:<doi>
```
És mindkettőnek egyeznie kell a CÍMMEL, nem csak léteznie. A v214 így fogott meg egy kitalált DOI-t: a 10.1080/01621459.1989.10478828 hihetőnek látszik a Laird & Louis 1989 ranking-cikkre, de egy MÁSIK JASA-cikkre mutat; a helyes 10.3102/10769986014001029 (Journal of Educational Statistics 14(1):29-46). A QMD-ből kinyert DOI-t lekérdezés előtt normalizáld: a markdown-escape-eket (\[, \]) ki kell venni, különben a jó hivatkozás is 404-et ad, és hamis „halott DOI”-ként jelenik meg ((bbbbbbbbb)-lecke).
A számos mondatot a knit UTÁN írd meg (v214 óta érvényes, (dddddddd)-lecke): a 8. pont kapuja a SZÁMOT hitelesíti (inline r, chunk-fedezet), a körülötte álló MONDATOT nem. A v214-ben három minősítés állt olyan chunk-fedett szám mellett, amit a szám cáfolt („közel a valós egy felhez” / 0.390; „tehát nem szignifikáns” / p = 0.011; „a többség” / 0.0 százalék), és mind a három átment a postgate-en és a scinot-scan-en. Az eljárás: a számos állításokat a knit UTÁN írd meg, vagy legalább a knit után olvasd újra a knittelt .md-t, és állítsd a mondatot a számhoz. A legolcsóbb söprés a minősítő szavakra megy:
```
grep -n "per cent\|close to\|most of\|majority\|so the\|therefore" <knit>.md
```
Importált „verifikált” headline előtt (rés-térkép, korábbi batch-status) először származtasd újra a skálafüggetlen mennyiséget, mert a 150 karakteres index-cella nem hordoz paraméterezést.
A hírlevél kadencia-vállalása KÖTELEZŐ (v282, 2026-09-05 óta): a Buttondown-lista első adása szó szerint ezt ígéri a feliratkozóknak: „No more than once a fortnight, and nothing else.” Ez session-független megkötés, és a napi 6-7 posztos deploy-kadenciától FÜGGETLEN: egy batch EGY levelet jelent, nem posztonként egyet, és két levél között legalább két hét telik el. A hírlevél tartalma csak új tutorialokról szól. Kapcsolódó megkötés ugyanabból az irányból: az R Weekly Live a 10 napnál frissebb posztokat szedi ki a feedből, tehát ha a poszt-kadencia végleg leáll, a feed-vonal és a hírlevél is elhal. Állapot és részletek: claude/v282-hirlevel.md.